That seems like a bug.

Suggestion:

Apply this modifier to a declaration to suppress any implicit
isolation that would ordinarily apply to it. For example, a
nonisolated property of an actor is not isolated to
self, and a nonisolated method of a @MainActor
class is not isolated to the main actor.

A nonisolated method or property is just like any other
function or variable that is not isolated to an actor. For
example, you can call a non-isolated synchronous method
of an actor from outside the actor without marking the call
with await. In turn, the body of the method or property is
treated as if it were outside the actor for isolation purposes.
For example, if you call an isolated method from a non-isolated
method, you must mark the call with await.

Maybe add an example showing this. Then I think we continue with the discussion of nonisolated types and extensions.

This doesn't seem right. I think this might be backwards — you've got it right below with "Sendable variables and properties".

Suggestion:

Swift restricts non-isolated stored variables so that they can provide
data isolation without using an actor. Non-isolated global
variables, static properties, and instance properties of actors and
sendable classes must be let constants of a sendable type.
Non-isolated instance properties of sendable structs must
have a sendable type, but they are allowed to be mutable.

If a stored variable meets the conditions for being nonisolated,
Swift will allow it to be used as if it were marked nonisolated
within the module that defines it. To use it as nonisolated
outside of that module, you must mark it nonisolated explicitly.

You can bypass these restrictions by marking a stored variable
nonisolated(unsafe). You are then responsible for ensuring
that the variable is only accessed in correctly-ordered ways.
This may be appropriate if, for example, you are protecting the
variable with a mutex and cannot use Swift's Mutex type.